Cloudflare オリジンルール（Origin Rules）ベータ版がリリースされたのでユースケースを紹介します。
どうも、ベルリンオフィスの小西です。
Cloudflare オリジンルール（Origin Rules） のベータ版がリリースされました。
オリジンルールは条件に一致したリクエストに対してトラフィックの送信先（オリジン）とパラメータをカスタマイズできる機能です。ホストヘッダー、SNI（Server Name Indication）、DNSレコード、宛先ポートのオーバーライドが可能です。
オリジンルールを使ってみる
使い方は非常に簡単でした。
Cloudflareダッシュボードにログインし、左サイドバー[Page Rules]から[Origin Rules]を選択します。
新規でオリジンルールを作成します。ダッシュボードの見通しがいいのはCloudflareの好きなところです。
適用条件として、例えば下記のヘッダーの値や項目が利用できます（一例）。
- Hostname
- IP Source Address
- Cookie
- Country
- Referer
- Request Method
- User Agent
- X-Forwarded-For
- URI
条件に合致したリクエストに対し、下記のアクションを設定できます。
- [Host Header]のリライト ( e.g. www.example.com )
- [Server Name Indication (SNI)]のリライト ( e.g. images.example.com )
- [DNS Record]のオーバーライド ( e.g. images.example.com )
- [Destination Port]のリライト ( eg. 8801 )
適用順位
今回Rules周りの多くの機能がbetaリリースされましたが、適用順序は下記になります。
トラフィックの流れ全体での各サービスの適用順位は下記です。
ユースケース
オリジンルールのユースケースを紹介します。
国ごとのオリジン振り分け
特定の国やリージョン（例えばEU圏内）からホスト名Aにアクセスしてきた訪問者に対して、ホスト名Bのコンテンツを返す、といったことが可能です。
国によって異なる昨今の個人情報保護方針に翻弄されるウェブサイト管理者の方も多いと思いますが、一部のリージョンに対して別のコンテンツを返すソリューションはわかりやすい使い所かと思います。
パスごとのオリジン変更
一つのドメイン内でも、特定のディレクトリへのアクセス時に異なるオリジンを返したいケースもあると思います。オリジンルールを使うことで、パスによって適切なオリジンを返すだけではなく、ホストヘッダーを同時に書き換えることで、オリジンとのホストヘッダー不一致を防ぐことが可能です。
すぐ思いつく例として、サイト内のアセットディレクトリへのアクセスのみを別オリジンにルーティングするケースです。
例えば example.com へのトラフィックは基本的に 98.51.100.12 に送信しつつ example.com/*.jpg へのリクエストのみを、img.example.com でアクセス可能なS3 バケットに送信する、といった設定ができます。
Cookieに応じたABテスト
リクエストに特定のCookieがあるかどうかを判定し、オリジンを分岐させるA/Bテストを行えます。アプリケーション側での設定や変更を最小限に抑えることができそうです。
ジオロケーションルーティングによるリクエスト待機時間短縮
配信アセットのストレージが複数のリージョンに分散されているスタックでは、 ip.geoip.country 条件を利用することで訪問者に対して地理的に最も近いストレージをルーティングできます。結果としてこれらのリクエストの待ち時間とロードにかかる時間を短縮できます。
ポート変更のプロキシサーバー的な役割
例えばバックエンドオリジンがポート8001のみでリッスンしている場合でも、CloduflareでHTTPSの標準的なポートである443をリッスンし、オリジンへのリクエストに際してポートを書き換えることができます。 リバースプロキシサーバーやオリジン側でのポートのプロキシ処理を代替することが期待できます。
注意点
通常のページルール（Page Rules）によるオーバーライドと重複した場合の挙動はどうなる？
既存のページルール（Page Rules）機能でも、リクエストに対してホストヘッダーやDNSレコード（Resolve Override）のオーバーライドが可能でしたが、今回のオリジンルールと重複して設定された場合はどちらが優先されるでしょうか。
その場合は オリジンルールが優先される とのことでした。
In this situation the Origin Rule parameters will override the Page Rule parameters.
また例えば、ページルール側でホストヘッダーのオーバーライド（Resolve Overrideは未設定）、オリジンルール側でDNSレコードのオーバーライドを設定した場合、対象のリクエストは「ページルールによって定義されたホストヘッダー」と、「オリジンルールによって定義されたホスト名（DNSレコード）」を持つことになります。
ロードバランサー設定との優先順位
例えばロードバランサー設定でヘッダー上書きが追加されていても、オリジンルールで設定がされていた場合はそちらが優先されます。
ページルールと同様に、ホストヘッダーのオーバーライドを行うオリジンルールは、元のリクエストのSNI値をホストヘッダーと同じ値に更新します。ホストヘッダーの上書きと異なるSNI値を設定するには、同じオリジンルールに任意のSNIの値でオーバーライドを追加するか、別のオリジンルールを追加する必要があります。
最後に
Cloudflareを通じたオリジンへのルーティングがより一層柔軟に、かつワンストップで対応できるようになりました。
個人的には、サイト内アセットが複数のホスト名に分散されているスタックでも、ワンストップでルーティングを追加できるのは助かるなと思いました。今までWorkersなどで対応していた処理も簡素化できるケースがあると思いますし、設定の見通しがよくなりそうです。オリジン側がレガシーな構成で仕様変更が難しい場合などにもフィットするケースが多そうです。
今回のオリジンルールだけではなくRules周りが全体で一層強化され、APIを通して利用可能になっているので、ぜひ試してみてください。
Classmethodでは、Cloudflareの構築支援・契約のご相談を承っています。ご興味のある方はぜひお問い合わせください。
